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DETAILED ACTION 

1 . This action is responsive to the AppUcant's response filed 1 1/22/2004. 

As indicated in Applicant's response, claims 1, 4, 8, 10, 13, 14, 17, 19 and 22 have been 
amended. Claims 1-2, 4-1 1, 13-20, and 22-25 are pending in the office action. 

Claim Rejections - 35 USC § 112 

2. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

3. Claims 1,6, 10, 15, 19, and 23 are rejected under 35 U.S.C. 112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

Claims 1,6, 10, 15, 19, and 23 recite the limitation "said needed resources" or "said 
resources needed" in lines 8, 2, 13, 2, 14, 2 of respective claims. There is insufficient antecedent 
basis for this limitation in the claim. Examiner will interpret this at best, as 'stack resources' 

Claim Rejections - 35 USC §103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 

section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 

such that the subject matter as a whole would have been obvious at the time the invention was made to a person * 

having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 

manner in which the invention was made. 

5. Claims 1-2, 4-7, 10-11, 13-16, 19-20, and 22-24 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Benson, USPN: 5,301,325 (hereinafter Benson), in view of Gosling, 
USPN: 5,668,999 (hereinafter Gosling). 
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As per claim 1, Benson discloses a method of monitoring processor resources, such 
method comprising: at the start of a block of code, performing just one test (e.g. col. 18, lines 12- 
27) for the block of code (e.g. nodes, flow graph - col. 12, line 21 to col. 13, line 47 - Note: flow 
graph visiting and nodes represented via tuple structures, each node having multiple instructions 
- see Fig. 6 , such node being visited reads on at the start to blocs of code including muhiple 
instructions), the blocs of code including multiple instructions (e.g.yZoiv graph ..Jink,,, tuples 
into node or blocks - col. 11, lines 1 1-22; node 4, 5, 6 -Fig, 8; block begin, block end - Fig. 4; 
Fig. 5-6) 

to determine at the start of said block of code if the resources of an architectural stack are 
correctly alloted for the block or have changed (e.g. stack depth ... with the node - col. 13, lines 
47 to col. 14, line 5; Fig. 12; col. 18, lines 12-27 - Note: for each node, determination as to 
whether stack resources are appropriately allotted or have changed reads on determining if 
resources are correctly set to be available when needed) for the instructions to be executed; and 

signaling an error if said resources needed for block of code are not correctly allotted 
(e.g. col. 4, lines 61-66; col. 13, lines 48-57). 

But Benson does not explicitly specify that the testing at the start of each block of code is 
for determining if the architectural stack resources needed by such block of code are available; 
nor does Benson expressly specify that signaling an error is in response to said stack resources 
(needed for the block of code) not being available. However, Benson discloses processing of 
block of code since starting entry point until exit points in the flow graph to determine stack 
depth discrepancy (e.g. col. 18, lines 13-19; Fig. 12), checking whether input/output registers are 
set at the beginning of head of a routine (e.g. Fig. 1 1 and related text); hence has taught the 
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requirement to see to it that references needed by the block of code internal instructions for being 
correctly set or adjusted (e.g. col. 13, lines 28-42; Fig. 16) for execution as well as stack depth 
allocation ( i.e. available resources) for correct execution of instructions or allocation registers 
needed for a procedure. The checking to verify whether data pushed in the stack are actually 
available for the runtime execution of code during a pre-runtime verification is further evidenced 
with GosHng's disclosure. Indeed, Gosling, in a similar method to verify program code to learn 
about stack information and changes using analogous checking and error notifying as Benson, 
discloses emulating the runtime stack in order to determine whether the virtual operands, 
variables, or instructions, i.e. resources needed for runtime code are correctly matched with a 
previously recorded snapshot of the emulated stack and generate error messages when they 
aren't matched (e.g. cols. 14-16, Appendix 1; Fig 4A-G; step 440 - Fig. 4B); hence has suggested 
how to check if the resources that will be needed for the runtime are available and correctly so. 
Based on Benson's intention to ensure that stack allocating of memory would not prevent correct 
execution of a block of code as mentioned above, it would have been obvious for one of ordinary 
skill in the art at the time the invention was made to enhance the graph node traversal and 
checking by Benson with the matching of runtime needed stack resources with pre-runtime 
emulated stack data, and generate error message when those resources are not available as taught 
by Gosling because this would enhance the method of Benson with timely integrity checking of 
code prior to runtime; and in so doing preclude stack overflow, and/or accommodate for data and 
platform discrepancies between environments in which the program is to be executed ( see 
Gosling: col. 1, hne 33 to col. 2, line 39). 
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Nor does Benson explicitly disclose that that the block of code instructions have adding 
data to the stack or removing data from the stack. Based on the teachings to investigate stack 
resources at the beginning of each node (col. 18, lines 13-19; Fig. 12), and the manipulating of 
registers as required in a course of a tuple analysis ( see Fig. 5) as well as the pushl, popl 
instructions for adjusting the stack when a node is visited ( col. 12, line 65, to col. 14, line 5), the 
limitation as code instructions for adding to or removing data from a stack is disclosed 

As per claim 2, Benson discloses determining a set of available resources for each block 
of code and check the correctness of stack allocation of such resources ( re claim 1) but does not 
explicitly specify determining that a set of such resources will be available after said block of 
code has been executed. However, Benson mentions about establishing resources state after the 
block of code has been executed (e.g. col 13, lines 28-40) and what next block of code needs to 
have checked (e.g. Fig. 16). In view of such systematic block of code traversal and in 
combination with the teachings by Gosling, the limitation as to determine the set of needed 
resources available after the previous block of code has been executed would have been obvious 
for the same rationale as set forth in claim 1 above; and because the checking cannot stop at one 
block of code to ensure the integrity of the runtime data when in opposite, all the blocks of code 
are to be verified. 

As per claim 4, Benson discloses availability of stack resources as in claim 1 being 
determined at compile time ( similar to a compiler -coV 4, lines 1-38 - Note: checking stack per 
node visit in order to ensure whether the CC or registers are entered - see Fig. 5, 11, 12 - reads 
on availability of stack resources checking). 
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As per claim 5, Benson does not explicitly disclose dynamically determining the 
resources; but Gosling discloses the verifier to be a dynamic program to check stack proper 
manipulations (e.g. col. 4, lines 47-59). Official notice is taken that the use of just-in-time 
compiler capabilities working of bytecodes in a cross-platform runtime environment ( e.g. JVM) 
to expedite the execution without recommitting compilation resources was a well-known concept 
by the time the invention was made. It would have been obvious for one of ordinary skill in the 
art at the time the invention was made to implement the block of code checking by Benson to 
include the determining of runtime needed stack resources as taught by Gosling using a dynamic 
verifier because this would enable Benson code to be byte code usable in byte code interpreting 
environments as mentioned by Gosling, thus obviating extraneous recompilation resources and 
extending the code usage of Benson's product as a cross platform applicability to more executing 
environments as taught by well-known practice set forth above using among others JVM and 
just-in-time compilation/interpretation. 

As per claims 6 and 7, Benson does not specify branching to a handler routine but 
Gosling discloses a exception handler routine (e.g. col. 12, lines 16-18); and it would have been 
obvious for one of ordinary skill in the art at the time the invention was made to implement such 
handler routine to Benson's method detects a dire fault in resources allocation found in the stack 
especially when Benson's application program is byte codes used in a dynamic environment like 
that suggested by Gosling in order to address data incompatibility issue in a dynamic manner 
without interrupting the application process flow, thus obviating extraneous recovery network or 
business resources. But in case of simulation as in Gosling' s teaching, simulating an exception 



Application/Control Number: 09/458, 1 2 1 Page 7 

Art Unit: 2124 

handling routine would also have been obvious in case the whole process of verifying resources 
is for a pre-runtime environment. 

As per claims 10-11, and 13-16, these claims are the computer-readable medium ( see 
Benson: disk 17 -Fig. 2 ) or apparatus claims corresponding to method claims 1-2 and 4-7, 
respectively, hence are rejected herein with the same reasons as set forth above. 

As per claim 19, Benson discloses a computer readable medium having a first set of 
instructions ( e.g. front-end ...input language, input to the translator - col. 8, lines 39-56), which 
when executed, generate a second set of instructions through a binary translation process, the 
second set of instructions (e.g. intermediate code - col 1 1, lines 8-22; Fig. 4) when executed 
cause the processor to perform a method comprising the steps of 

performing only one test at the start of a block code (resources . . . stack are available); 

the block of code including multiple instructions ( adding/removing); and 

signaling (. . .resources not available) just as have been recited in claim 1 above. 

Hence these step limitations are rejected using the corresponding rejection of claim 1 as 
set forth therein, including the rationale with the obvious motivation to combine Benson and 
Gosling. 

As per claims 20 and 22-24, these claims are the computer-readable medium claims 
corresponding to method claims 2 and 5-7, respectively, hence are rejected herein with the same 
reasons as set forth above. 

6. Claims 8-9, 17-18, and 25 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Benson, USPN: 5,301,325 and Gosling, USPN: 5,668,999; as applied to claims 1, 10, and 19, 
respectively; and further in view of Yellin et al,, USPN: 5,740,44 1( hereinafter Yellin). 
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As per claim 8, Benson does not specify using bit vector to represent stack resources but 
does provide condition code and tuple to represent resources in a flow graph tree (e.g. Figs. 5-6) 
while Gosling discloses using exception handler but in a method to pre-verify correctness of data 
prior to runtime using snapshot of stack to emulate runtime data requirements similar to that of 
Gosling, Yellin discloses using bit vector to implement the jump subroutines with bit vector to 
expedite the reaching to subroutine address (e.g. col. 6, lines 6-23; Fig. 3 - Note: status array 
including bit reads on bit vector). To implement a dynamic checking as mentioned in claim 6 
above, it would have been obvious for one of ordinary skill in the art at the time the invention 
was made to implement a bit vector as taught by Yellin to the resources investigated from the 
stack in Benson/Gosling's combination to expedite the process of traversing the flow of block of 
code for verifying of routines, thus to maintain the dynamic resources integrity checking and 
averting usage of error recovery resources during a runtime environment ( e.g. byte code in JIT 
machine) where possibly processor and/or volatile resources would be hmited, such potential 
limitation being well known in remote devices ( e.g. wireless devices) in which the distributed 
byte codes as taught by Gosling are downloaded and executed. 

As per claim 9, Benson and Gosling do not mention about bit vector; but Gosling 
mentions about simulating in a dynamic environment and using exception handling ( re claims 5 
and 6). Further, in view of Yellin' s teaching of bit vector in a stack emulation environment 
similar to Gosling, the limitation as to generate a bit vector dynamically would also have been 
obvious for the same reasons as mentioned in claim 8 above. 
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As per claims 17-18, these claims are the computer-readable medium claims 
corresponding to method claims 8-9 above, respectively, hence are rejected herein with the same 
reasons as set forth above. 

As per claim 25, this claim is the computer-readable medium claim corresponding to 
method claim 8, and is rejected herein with the same reasons as set forth above. 

Response to Arguments 
7. Applicants arguments filed 1 1/22/2004 have been fully considered but they are not 
persuasive. Following are the most representative arguments raised by Applicants and the 
corresponding responses by Examiner. 

(A) Applicants have submitted that Benson is not 'testing at a start of . . . block of code to 
determine if resources ... needed by a block of code, as claimed by applicant'; and that Benson 
actually discloses processing each instruction ( within routines) individually while maintaining 
an offset (Appl. Rmrks, pg. 9, middle 2 paras ). 

First, the claims no longer recite 'resources that are needed by a block of code'. 
Second, unlike Applicants' line of approach, the rejection has been directed to 
specifically map a different portion of the Benson reference to read on 'at the start of a block of 
code ... are available for the block of code', i.e. Benson upon visiting of a node, checks that the 
corresponding stack depth to determine whether discrepancy exists ( see cited portions). And 
effecting such a checking at the start of a node is not the same as processing each instruction 
individually within a routine as asserted by Applicants because each node being visited includes 
multiple instructions; thus read on block of code. In other words, the rejection points to specific 
parts of Benson in which at the entry point to each node being visited a stack depth is checked - 
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only one check - to fathom stack allocation; and this substantially reads on the claims limitation 
as have been construed by Examiner. Indeed, the Hmitation as to testing at the start of each 
block of code, to determining if resources of an architectural stack that are available is 
substantially, if not entirely, covered by Benson's checking of stack depth ( see Fig. 12) when 
starting to analyze a node wherein CC and input registers are being addressed as a result of such 
checking. Since Benson does not expressly disclose whether the resources are available for the 
block of instructions to be executed. Gosling has been brought in to enhance Benson's intended 
method of checking stack correctness while traversing flow graph or blocks of code. 

Third, the claims as recited and interpreted in regard to the above limitation do not 
preclude one test to check stack depth to be similar to a method for ensuring that resources are 
being properly available. Nor does it impose that any given test -- like that of Benson being 
effected at the beginning of a node visit — to consist of a non-repeated and sole step, A test even 
though appHed one time as is in Benson's case can include more than one internal step but since 
the claim is not specific about this, such test that is being performed one time for each node does 
read on the claim. Applicants appear to have taken that a program routine with many 
instructions therein such that these are sequentially processed is to be the block of code lending 
the teaching that more test steps are performed. The claim is not clear on the notion of 'only 
one' test, i.e. a test with sole or many internal steps as mentioned above. The rejection has 
referred to a node as being such a block; thus, the above argument that Benson processes 
successively individual instruction of a block of code becomes moot or misdirected. 
(B) In short, as set forth in the rejection, at the start of each block, a test has been made to 
find out if stack resources for that particular block are correctly set for execution of that block. 
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The rationale as to combine Benson's intention with Gosling's emulation method has been set 
forth in the rejection. AppHcants while pointing other aspects of Benson's method, actually fail 
to point out how the combined teachings by Benson and Gosling teach away from claim 1 
limitation; nor are appHcants able to prove that Benson's checking of stack-depth is outright 
inapposite or contradictory with the claimed limitation 

Therefore, the rejections will stand as set forth in the Action. 

Conclusion 

8. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization whae this application or proceeding is assigned is (571) 273- 
3735 ( for non-official correspondence - please consult Examiner before using) or 703-872-9306 ( for official 
correspondence) or redirected to customer service at 571-272-3609. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published apphcations 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
apphcations is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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